Volume 2

Issue 3

September 2005

Information Architecture Constructing with content Pamela Kostur The Rockley Group kostur@rockley.com Content reuse is key to content management. Content reuse means that you can write content once and use it wherever required, but it also means that you have to write content consistently so that it can be reused. This article describes the concept of "constructing with content", comparing it to constructing with LegoTM, and describes how to prepare your content for reuse. Content as LegoTM I like to think of content as Lego building blocks-those colourful plastic blocks you played with as a child (or as an adult!), building castles, forts, and other architectural wonders. Lego blocks come in various sizes, each designed for a particular function, and with colours that indicate their function. You select the appropriate pieces, then build your creation. If you use a piece in the wrong place, it will not fit with the other pieces and your masterpiece could fall apart. Constructing information products follows a similar process. In a content reuse situation, information products are constructed from elements that are designed and written to a standard that supports their various purposes. If the elements do not conform to the purpose for which they are intended, your construction may fall apart, the same way your Lego castle could fall apart if you use roof pieces to construct the walls! Also, the roof pieces must conform to a "roof standard" and the wall pieces must conform to a "wall standard", ensuring that the roofs and walls will be solid and that the pieces will fit together. Designing content building blocks Likewise, content must be always designed for the ways in which it is used, especially when content components are reused to create other information products. So, what do you have to do to prepare your content so that it is reusable? Just like with Lego building blocks, you have to make sure that the pieces fit together and that they are easily identifiable so their purpose is clear to those who use them. To ensure your content pieces will work together, you need to create a standard for each component included in your "box of content pieces". Think of the box of Lego as your CMS, or database. Think of the Lego pieces as your content components. So, where to start? When you're constructing with content, the first thing you have to do is to figure out where the content will be used-where, in your information product construction must that piece fit. This is what you're doing when you create content models; you're designing the structure of the "building". Then, you have to figure out the structure of each of the pieces in the "building", ensuring they will fit together, even if used in a different building. For example, when building with Lego, you can make the item identified in a Lego kit, or you can use the Lego pieces to make other items. Whatever you decide to build, the pieces have to work together. It's important to define the structure of each of the pieces because unless they are written according to a standard, the integrity of your information products in which the pieces are used may be compromised. From a content modeling perspective, structure defines the hierarchical order in which information occurs, but from a writing perspective, structure defines the way the content within each hierarchical element is written. The content model documents the structure of information products, which is then implemented in a DTD/authoring template that helps to enforce it. (Similarly, the Lego set may come with a design showing you how to put a particular item together and while not enforced, it provides a guideline-a set of "rules".) However, structure goes beyond defining how an information product is put together. For information products to be truly unified, content must be structured and written the same way, so it "works" wherever it is used, just like the Lego pieces have to be unified so they work regardless of what you decide to build with them. For example, the model for a procedure will tell you the elements that make up a procedure (such as overview, steps, results, cautions), which of those elements are mandatory and which are optional, the order in which they appear, and which elements are reused elsewhere. However, the model doesn't tell you how those elements must be written. This is where structured writing comes in. Structured writing provides the standards for how to structure and write the elements of content in your information products and is necessary to prepare your content for reuse. Why is structure so important? When implementing a unified content strategy, it's critical that authors structure and write their content consistently. Well-structured content leads to more opportunities for reuse across product lines, audiences, and information products. In a structured-writing environment, authors follow the same structure rules or guidelines for each element of content, ensuring its potential reuse. Many problems can arise when content is not structured to support its various uses and users. Not only is unstructured writing difficult for users to follow, it's also difficult for authors to create. For example, without structured writing guidelines for procedures, some authors may include results within their steps, while others don't. And, even if they do include the result portion of the step, they may include different information within it, or use different grammatical structures than other authors. If steps are to be reusable across information products, they must be structured and written the same, so their reuse is transparent to both authors and to users. Imagine trying to build a Lego construction with pieces that look like they should go together, but just don't fit. They appear to be wall pieces, but the wall pieces just don't work together. You end up trying to cram them into place, most certainly compromising the integrity of the structure. Structuring and writing content consistently not only makes it possible for you to reuse content transparently; it also enhances information products' usability. Implementing a unified content strategy is an ideal time to examine your content for usability, to create usability criteria that define what makes content usable for each of its intended audiences, and to include usability criteria in your writing guidelines. Simply reusing content can facilitate usability (by reusing content, it is the same wherever it appears), but if that content is poorly-written or is open to interpretation, it is not usable, regardless of how well it conforms to the structure or how frequently it is reused. If you reuse unusable content, it's certainly the same wherever it appears, but it's also unusable everywhere it appears. In addition to defining consistent structures for your content you must also examine the content itself to ensure it is accurate, readable, and not open to interpretation. Then, you can decide how to structure and write it to enhance usability. Implementing structured writing Implementing structured writing as part of a unified content strategy has three main steps: Analyze - Define all information requirements up front, determine what information products do you need to create, for whom, for what purpose (decide which kinds of constructions your Lego set will support, e.g., houses or vehicles). Design - Create content models to accommodate your information requirements, indicating where content can be reused (figure out where your Lego pieces can be used to create other constructions, e.g., can the house and vehicle sets share pieces). Write - Create structured writing guidelines. Determine how to structure and write the content for each element in your models (determine how the Lego pieces must be constructured to support their use in different constructions, e.g., how must the reusable pieces be constructed so they work in both the house and vehicle sets). Some tips for creating structured writing guidelines are to: Separate content from format Because the pieces of content may be used in different places, think about what the content must say and how that content must be written instead of how it will appear on the page. Lego designers don't always know how their pieces will be used, so they must focus on how that piece must function to work wherever users decide to use it. Structure similar kinds of components in the same way So reuse is transparent, design standards for similar types of content. For example, design a standard for steps so that steps are always structured and written the same way. Do they contain a result or not? How is that result reflected in the step? Once you've defined the standard for a step, you can use that standard for all steps, in all information products. Think of what information types you have (e.g., concepts, processes, procedures) and design standards that accommodate that particular information type. Refer to information theory Allow information theory to inform the standards for your content. Look to information theory for guidance in such things as chunking (how big should a chunk be), labeling (which chunks are given labels and how are those labels written), relevance (what constitutes relevant content for each chunk), and above all, usability (what usability criteria apply to each content component). Summary In a content management environment, you decide what the structure of your information products should be, document the structure in models, implement the models in authoring templates, create writing guidelines for each element, then manage the elements in a definitive source where they are accessible to all those who need to "build" information products. Just like Lego pieces are designed to support reuse in building Lego constructions, content must be designed to support reuse in constructing information products. When you're constructing with content, you need to think about how each of the components is designed (both the structure and the content within the structure), ensuring the integrity of your construction.